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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This document describes a set of Extension Headers for the 
Unidirectional Lightweight Encapsulation (ULE), RFC 4326. 


The Extension Header formats specified in this document define 
extensions appropriate to both ULE and the Generic Stream 
Encapsulation (GSE) for the second-generation framing structure 
defined by the Digital Video Broadcasting (DVB) family of 
specifications. 
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Les 


Introduction 


This document describes three Extension Headers that may be used with 
both the Unidirectional Lightweight Encapsulation (ULE) [RFC4326] and 
the Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for 
links that employ the MPEG-2 Transport Stream, and supports a wide 
variety of physical-layer bearers [RFC4259]. 


GSE has been designed for the Generic Mode (also known as the Generic 
Stream (GS)), offered by second-generation DVB physical layers, and 
in the first instance for DVB-S2 [ETSI-S2]. The requirements for the 
Generic Stream are described in [S2-REQ]. The important 
characteristics of this encapsulation are described in the appendix 
of this document. GSE maintains a design philosophy that presents a 
network interface that is common to that presented by ULE and uses a 
similar construction for SubNetwork Data Units (SNDUs). 


The first Extension Header defines a method that allows one or more 
TS Packets [ISO-MPEG2] to be sent within a ULE SNDU. This method may 
be used to provide control plane information including the 
transmission of MPEG-2 Program Specific Information (PSI) for the 
Multiplex. In GSE, there is no native support for Transport Stream 
packets and this method is therefore suitable for providing an MPEG-2 
control plane. 


A second Extension Header allows one or more PDUs to be sent within 
the same ULE SNDU. This method is designed for cases where a large 
number of small PDUs are directed to the same Network Point of 
Attachment (NPA) address. The method may improve transmission 
efficiency (by removing duplicated MAC layer overhead). It can also 
reduce processing overhead for a receiver that is not configured to 
receive the NPA address associated with an SNDU, allowing this 
receiver to then skip several PDUs in one operation. The method is 
defined as a generic Extension Header and may be used for IPv4 or 
IPv6 packets. If, and when, a compression format is defined for ULE 
or Ethernet, the method may also be used in combination with this 
method. 


A third Extension Header provides an optional TimeStamp value for an 
SNDU. Examples of the use of this TimeStamp option include 
monitoring and benchmarking of ULE and GSE links. Receivers that do 
not wish to decode (or do not support) the TimeStamp extension may 
discard the extension and process the remaining PDU or Extension 
Headers. 


The appendix includes a summary of key design issues and 
considerations relating to the GSE Specification defined by the DVB 
Technical Module [GSE]. 
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Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


b: bit. For example, one byte consists of 8b. 

B: byte. Groups of bytes are represented in Internet byte order. 
BBFrame payload: The data field part of a Baseband frame [ETSI-S2] 
that may be used for the communication of data. Typical BBFrames 


range in size from 3072 to 58192 bits according to the choice of 
modulation format and Forward Error Correction (FEC) in use. 


DVB: Digital Video Broadcasting. A framework and set of associated 
standards published by the European Telecommunications Standards 
Institute (ETSI) for the transmission of video, audio, and data. 


E: A one-bit flag field defined in GSE [GSE]. 
Encapsulator: A network device [RFC4259] that receives PDUs and 


formats these into Payload Units (known here as SNDUs) for output in 
DVB-S or the Generic Mode of DVB-S2. 


GS: Generic Stream. A stream of BBFrames identified by a common 
Input Stream Identifier, and which does not use the MPEG-2 TS format 
[ETSI-S2]. It represents layer 2 of the ISO/OSI reference model. 


GSE: Generic Stream Encapsulation [GSE]. A method for encapsulating 
PDUs to form a Generic Stream, which is sent using a sequence of 
BBFrames. This encapsulation format shares the same extension format 
and basic processing rules of ULE and uses a common IANA Registry. 


LT: A two-bit flag field defined in GSE [GSE]. 


MAC: Medium Access Control [IEEE-802.3]. A link-layer protocol 
defined by the IEEE 802.3 standard. 


MPEG-2: A set of standards specified by the Motion Picture Experts 
Group (MPEG), and standardized by the International Organization for 
Standardization (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220). 


Next-Header: A Type value indicating an Extension Header [RFC4326]. 


Fairhurst & Collini-Nocker Standards Track [Page 3] 


RFC 5163 Extension Formats for the ULE Encapsulation April 2008 


NPA: Network Point of Attachment [RFC4326]. In this document, refers 
to a destination address (resembling an IEEE MAC address) within the 
DVB-S/S2 transmission network that is used to identify individual 
Receivers or groups of Receivers. 


PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the 
header of each TS Packet. This identifies the TS Logical Channel to 
which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the 
parts of a Table Section or other Payload Unit must all carry the 
same PID value. The all-ones PID value indicates a Null TS Packet 
introduced to maintain a constant bit rate of a TS Multiplex. There 
is no required relationship between the PID values used for TS 
Logical Channels transmitted using different TS Multiplexes. 


PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include 
Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. 


PSI: Program Specific Information [ISO-MPEG2]. 

S: A one-bit flag field defined in [GSE]. 

SI Table: Service Information Table [ISO-MPEG2]. In this document, 
this term describes a table that is been defined by another standards 
body to convey information about the services carried on a DVB 


Multiplex. 


SNDU: SubNetwork Data Unit [RFC4259]. In this document, this is an 
encapsulated PDU sent using ULE or GSE. 


Stream: A logical flow from an Encapsulator to a set of Receivers. 
TS: Transport Stream [ISO-MPEG2], a method of transmission at the 


MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI 
reference model. 


ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A 
method that encapsulates PDUs into SNDUs that are sent in a series of 
TS Packets using a single TS Logical Channel. The encapsulation 


defines an extension format and an associated IANA Registry. 


3. Description of the Method 


In ULE, a Type field value that is less than 1536 in decimal 
indicates an Extension Header. This section describes a set of three 
extension formats for the ULE encapsulation. [GSE] uses a Type field 
that adopts the same semantics as specified by RFC 4326. The 
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encapsulation format differs in that GSE does not include a Cyclic 
Redundancy Check (CRC) for each SNDU, has different header flags, and 
utilizes a different SNDU length calculation [GSE]. 


There is a natural ordering of Extension Headers, which is determined 
by the fields upon which the Extension Header operates. A suitable 
ordering for many applications is presented in the list below (from 
first to last header within an SNDU). This does not imply that all 
types of Extensions should be present in a single SNDU. The 
presented ordering may serve as a guideline for optimization of 
Receiver processing. 


eC Cm aa a aa aa ee a : apne cae oa aca a cr a OR + 
|Fields related to Extension Header| Example Extension Headers | 
Pres r Se SSeS aaa saeeSs assesses ssSses $oqSeHssaa nen essen esses + 
| Link framing and transmission | TimeStamp Extension | 
scam ac aa eae E eS SSeS ee ee + 
| Entire remaining SNDU Payload | Encryption Extension | 
san Fn + 
| Group of encapsulated PDUs | PDU-Concat or TS-Concat 

hee oS See ee eee oS see ee ee + 

Specific encapsulated PDU TEEE-defined type 
Test or MAC bridging Extension 

$e See SSS SS a Se Se eS ee Se Sess SSS SSS SS SS See SS Se See ee + 


Table 1: Recommended ordering of Extension Headers 


3.1. MPEG-2 TS-Concat Extension 


The MPEG-2 TS-Concat Extension Header is specified by an IANA- 
assigned H-Type value of 0x0002 in hexadecimal. This is a Mandatory 
Extension Header. 


The extension is used to transport one or more MPEG-2 TS Packets 
within a ULE SNDU. The number of TS Packets carried in a specific 
SNDU is determined from the size of the remainder of the payload 
following the MPEG-2 TS Extension Header. The number of TS Packets 
contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N 
is the number of bytes associated with Extension Headers that precede 
the MPEG-2 TS-Concat Extension (zero if there are none) and D is the 
value of the D-bit. 


A Receiver MUST check the validity of the Length value prior to 
processing the payload. A valid Length corresponds to an integral 
number of TS Packets. An invalid Length (a remainder from the 
division by 188) MUST result in the discard of all encapsulated TS 
Packets and SHOULD be recorded as TS-Concat size mismatch error. 
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Oo D2) 3 AH 9:6. B90 2: 3) 48 6 B96 OWL 2 BG An 3) 162 F887 98 Oi 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +++ 
|o] Length (15b) | Type = 0x0002 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
Receiver Destination NPA Address (6B) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| 

—4+-4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4 

TS-Packet 1 | 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
TS-Packet 2 (if Length > 2*188) 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
(CRC-32) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ 
| 
etc. | 
+ 
| 


recom deat grat se ee pe ao 
+ 
l 
+ 
l 
+ 
l 


Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0) 


Figure 1 illustrates the format of this Extension Header for ULE with 
a value D=0, which indicates the presence of an NPA address 
[RFC4326]. In this case, the valid payload Length for a ULE SNDU 
with no other extensions is (Length-10) / 188. 


The method used to define the Length in GSE differs to that of ULE. 
The equivalent case for GSE would result in a payload Length value of 
(Length-6) / 188 (Figure 2). 


(O 2 BAS E 8.9 0.1: 23 4 So 6.2 FB: O 23" AP 3s 160 8 O 


TS-Packet 2 (if Length > 2*188) 


etc. 
—+—+-—4+-4-4-4+-4+-4+-4+-4-4-4+-4+-4+-4-4+-4-4-4-—4+-4+-4-4+-4+-4+-4+-4+-4+-4+-4+-4+-4+ 


+—t-F-+-4-4-4F-4-4-4-4F 4-4-4 -4F 4-4-4 -4F-F -F-F -F FF - FF HF HF FF Ft 
|s|E|o o| Length (12b) | Type = 0x0002 | 
+—t—f-4-4-4-4F-4-4-4-4F 4-4-4 -F 4-4 -F FF FFF HF HHH FF Ft tt 
| Receiver Destination NPA Address (6B) 

+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| TS-Packet 1 | 
+—t-F-+-4-4-4F-4-4-4-4F 4-4-4 -F 4-4 -4F-F FF FF FFF FHF HF $$$ 
+ 


Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00) 
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Fragmented GSE SNDUs are protected by a CRC-32 carried in the final 
fragment. After reassembly, this CRC-32 is removed and the resulting 
SNDU carries a Total Length field. The fields labeled S and E are 
defined by [GSE] and contain control flags used by the GSE link 
layer. The Label Type (LT) field specifies the presence and format 
of the GSE label. The LT field is only specified for the first 
fragment (or a non-fragmented) GSE SNDU (i.e., when S=1). 


In ULE, a value of D=1 is also permitted and indicates the absence of 
an NPA address (Figure 3). A similar format is supported in GSE. 


0 i 2 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|1| Length (15b) | Type = 0x0002 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
TS-Packet 1 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
TS-Packet 2 (if Length > 2*188) 


etc. 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++HH 
(CRC-32) | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++HH 


+— +— I —+— 1 — 


Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1) 


The TS-Concat extension may be used to transport one or more MPEG-2 
TS Packets of arbitrary content, interpreted according to [ISO- 
MPEG2]. One expected use is for the transmission of MPEG-2 SI/PSI 
signalling [RFC4259]. 


NULL TS Packets [ISO-MPEG2] SHOULD NOT be sent using this 
encapsulation. To reduce transmission overhead and processing, an 
Encapsulator SHOULD specify a maximum period of time that it can wait 
before sending all queued TS Packets. This is known as the TS 
Packing Threshold. This value MUST be bounded and SHOULD be 
configurable in the Encapsulator. A larger value can improve 
efficiency, but incurs higher jitter and could increase the 
probability of corruption. If additional TS Packets are NOT received 
within the TS Packing Threshold, the Encapsulator MUST immediately 
send any queued TS Packets. 


The use of this format to transfer MPEG-2 clock references (e.g., a 


Network Clock Reference, NCR) over ULE/GSE framing raises timing 
considerations at the encapsulation gateway, including the need to 
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update/modify the timing information prior to transmission by the 
physical layer. These issues are not considered here, but this 
operation may be simplified in GSE by ensuring that all SNDUs that 
carry this Extension Header are placed before other data within the 
BBFrame DataField [GSE]. 


This document does not specify how TS Packets are to be handled at 
the Receiver. However, it notes: 


* A Receiver needs to consistently associate all TS Packets ina 
Stream with one TS Logical Channel (Stream). If an Encapsulator 
transmits more than one Stream of TS Packets each encapsulated at a 
different level or with a different NPA address, a Receiver needs 
to ensure that each is independently demultiplexed as a separate 
Stream (Section 3.2 [RFC4259]). 


* If an Encapsulator transmits service information encapsulated at 
different levels or with different NPA addresses, the Receivers 
need to ensure each Stream is related to the corresponding SI table 
information (if any). A RECOMMENDED way to reduce signaling 
interactions is to ensure each PID value uniquely identifies a 
Stream within a TS Multiplex carrying ULE and also any TS Packets 
encapsulated by a ULE/GSE Stream. 


The need for consistency in the use of PIDs and the related service 
information is described in section 4.2 of [RFC4947]. 


3.2. PDU-Concat Extension 


The PDU-Concat Extension Header is specified by an IANA-assigned 
H-Type value of 0x0003 in hexadecimal. This is a Mandatory Next- 
Header Extension. It enables a sequence of (usually short) PDUs to 
be sent within a single SNDU Payload. 


The base header contains the Length of the entire SNDU. This carries 
the value of the combined length of all PDUs to be encapsulated, 
including each set of encapsulation headers. The base header MAY be 
followed by one or more additional Extension Headers that precede the 
PDU-Concat Extension Header. These Extension Headers (e.g., a 
TimeStamp Extension) apply to the composite concatenated PDU. 


The Extension Header also contains a 16-bit ULE Type field describing 
the encapsulated PDU, PDU-Concat-Type. Although any Type value 
specified in the ULE Next-Header Registry (including Extension Header 
Types) may be assigned to the encapsulated PDU (except the recursive 
use of a PDU-Concat type), all concatenated PDUs MUST have a common 
ULE Type (i.e., all concatenated PDUs passed by the network layer 
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must be associated with the same Type value). This simplifies the 
receiver design, and reduces the transmission overhead for common use 
cases. 


Each PDU is prefixed by its length in bytes (shown in the following 
diagrams as PDU-x-Length for the xth PDU). Encapsulated PDUs are of 
arbitrary length (in bytes) and are not necessarily aligned to 16-bit 
or 32-bit boundaries within the SNDU (as shown in the figures 4, 5, 
and 6). The most significant bit of the first byte is reserved, R, 
and this specification requires that this MUST be set to zero. 
Receivers MUST ignore the value of the R bit. The length of each PDU 
MUST be less than 32758 bytes, but will generally be much smaller. 


When the SNDU header indicates the presence of an SNDU Destination 
Address field (i.e., D=0 in ULE), a Network Point of Attachment, NPA, 
field directly follows the fourth byte of the SNDU header. NPA 
destination addresses are 6 byte numbers, normally expressed in 
hexadecimal, used to identify the Receiver(s) in a transmission 
network that should process a received SNDU. When present, the 
Receiver MUST associate the same specified MAC/NPA address with all 
PDUs within the SNDU Payload. This MAC/NPA address MUST also be 
forwarded with each PDU, if required by the forwarding interface. 


O223 45 6789022345678 9 01422345678 9.01 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|o] Length (15b) | Type = 0x0003 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Receiver Destination NPA Address (6B) 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
PDU-Concat-Type 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
PDU-1-Length (15b) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

PDU-1 


| 
+ 
| 
+ 


w 
+—+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
PDU-2-Length (15b) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
PDU-2 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


w 
+—+ 


+—+ 
— Ii +—+— I +— + — + — + 


— Ii +— + — I +— + — + — 


More PDUs as required 


+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ +++ 
(CRC-32) | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +++ 


ii 
+ 
| 
+ 


Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0) 
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O02? 3+ 4-5 56 B90 2. 3) Ab OE 8 9. OVAL 2S) 4 6 Be 980i 
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
s|eļo o| Length (12b) | Type = 0x0003 
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Receiver Destination NPA Address (6B) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
PDU-Concat-Type 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
PDU-1-Length (15b) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


PDU-1 


| 
+ 
| 
+ 


w 
+—+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
PDU-2-Length (15b) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
PDU-2 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


w 
+—+ 


— I +—+— I +— +— +— ++ 
+—+ 


— I +—+— I +— + — + — ++ 


More PDUs as required 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00) 
When the SNDU header indicates the absence of an SNDU Destination 
Address field (i.e., D=1 in ULE), all encapsulated PDUs MUST be 
processed as if they had been received without an NPA address. 
The value of D in the ULE header indicates whether an NPA/MAC address 


is in use [RFC4326]. A similar format is supported in GSE (using the 
LT field). 
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0o 123-45 67° e 9-0-2 3 45°67 g 9. 0:12.34. 5 6°97 -B9950 1 
SHH tata ta toto tartar tr trtr toto ta tatatatatatatata ta tata tata to toto tat 
Length (15b) | Type = 0x0003 
a a ea em cle a ea ae ae el ee et em eet eo Cee ee ce a ea a oe 
PDU-Concat—Type |R] PDU-1-Length (15b) 
egal erecta cic le a aa ae eel Se ae ee ie Sei leat Cee la a eo er ata ce eh a 
PDU-1 


bh 


+—+— 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
PDU-2-Length (15b) | | 
+ 


A 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
PDU-2 


— I +—+— I +—+— + 


More PDUs as required 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
(CRC-32) | 
+-+-+-+-+-+-+-+-+-+-+++ +++ HHHH 


+ 


Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1) 


To reduce transmission overhead and processing, an Encapsulator 
SHOULD specify a maximum period of time it will wait before sending a 
Concatenated PDU. This is known as the PDU Packing Threshold. This 
value MUST be bounded and SHOULD be configurable in the Encapsulator. 
A larger value can improve efficiency, but incurs higher jitter and 
could increase the probability of corruption. If additional PDUs are 
NOT received within the PDU Packing Threshold, the Encapsulator MUST 
immediately send all queued PDUs. 


The Receiver processes this Extension Header by verifying that it 
supports the specified PDU-Concat Type (unsupported Types MUST be 
discarded, but the receiver SHOULD record a PDU-Type error 
[RFC4326]). It then extracts each encapsulated PDU in turn. The 
Receiver MUST verify the Length of each PDU. It MUST also ensure 
that the sum of the Lengths of all processed PDUs equals the Length 
specified in the SNDU base header. A Receiver SHOULD discard the 
whole SNDU if the total and PDU sizes are not consistent and this 
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event SHOULD be recorded as a PDU-Concat size mismatch error. A 
receiver MUST NOT forward a partial PDU with an indicated PDU-Length 
greater than the number of unprocessed bytes remaining in the SNDU 
payload field. 


3.3. TimeStamp Extension 


The TimeStamp Extension Header is an Optional Extension Header that 
permits an Encapsulator to add a TimeStamp field to an SNDU. The 
TimeStamp Extension Header is specified by the IANA-assigned H-Type 
value of 257 decimal. This extension is an Optional Extension Header 
([RFC4326], Section 5). 


This extension is designed to support monitoring and measurement of 
the performance of a link to indicate the quality of an operational 
ULE link. This may be useful for GSE links (e.g., where significant 
complexity exists in the scheduling provided by the lower layers). 
Possible uses of this extension include: 


* Validation of in-sequence ordering per Logical Channel 

* Measurement of one-way delay (when synchronized with the sender) 
* Measurement of PDU Jitter introduced by the link 

* Measurement of PDU loss (with additional information from sender) 


Figure 7 shows the format of this extension with a HLEN value of 3 
indicating a TimeStamp of length 4B with a Type field (there is no 
implied byte-alignment). 


0 7 15 23 31 
+--------------- +--------------- +--------------- +--------------- + 
| 0x03 | 0x01 | TimeStamp HI 
+--------------- +--------------- +--------------- +--------------- + 
| TimeStamp LO | Type | 
+--------------- +--------------- +--------------- +--------------- + 


Figure 7: Format of the 32-bit TimeStamp Extension Header 


The extension carries a 32-bit value (TimeStamp HI plus TimeStamp 
LO). The specified resolution is 1 microsecond. The value therefore 
indicates the number of 1-microsecond ticks past the hour in 
Universal Time when the PDU was encapsulated. This value may be 
earlier than the time of transmission, due for example to Packing, 
queuing, and other Encapsulator processing. The value is right- 
justified to the 32-bit field. Systems unable to insert TimeStamps 
at the specified resolution MUST pad the unused least-significant 
bits with a value of zero. 
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The last two bytes carry a 16-bit Type field that indicates the type 
of payload carried in the SNDU or the presence of a further Next- 
Header ([RFC4326], Section 4.4). 


Receivers MAY process the TimeStamp when the PDU encapsulation is 
removed. Receivers that do not implement, or do not wish to process, 
the TimeStamp Extension MAY skip this Extension Header. Receivers 
MUST continue to process the remainder of the SNDU, forwarding the 
encapsulated PDU. 


4. IANA Considerations 


IANA has assigned three new Next-Header Type values from the IANA ULE 
Next-Header Registry. These options are defined for specific use 
cases envisaged by GSE, but are compatible with ULE. 


The following assignments have been made in this document and 
registered by IANA: 


Type Name Reference 
2: TS-Concat Section 3.1 
Si PDU-Concat Section 3.2 
Type Name H-LEN Reference 
2578 TimeStamp 3 Section 3.3 


The TS-Concat Extension is a Mandatory next-type Extension Header, 
specified in Section 3.1 of this document. The value of this next- 
header is defined by an IANA assigned H-Type value of 0x0002. 


The PDU-Concat Extension is a Mandatory next-type Extension Header 
specified in Section 3.2 of this document. The value of this next- 
header is defined by an IANA assigned H-Type value of 0x0003. 


The TimeStamp Extension is an Optional next-type Extension Header 
specified in Section 3.3 of this document. The value of this next- 
header is defined by an IANA assigned H-Type value of 257 decimal. 
This documents defines the format for an HLEN value of 0x3. 
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Security Considerations 


Security considerations for ULE are described in [RFC4326], and 
further information on security aspects of using ULE are described in 
the security considerations of [RFC4259] and [Sec-Req]. 


An attacker that is able to inject arbitrary TS Packets in a ULE or 
GSE Stream may modify layer 2 signalling information transmitted by 
the MPEG-2 TS-Concat extension. Since this attack requires access to 
the link and/or layer 2 equipment, such an attack could also directly 
attack signalling information sent as native TS Packets (not 
encapsulated by ULE/GSE). Security issues relating to the 
transmission and interpretation of layer 2 signalling information 
(including Address Resolution) within a TS Multiplex are described in 
[RFC4947]. The use of security mechanisms to protect the MPEG-2 
signalling information is discussed by [Sec-Req]. 
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Appendix A. The Second-Generation DVB Transmission Specifications 


This section provides informative background to the network-layer 
requirements of the second-generation DVB Transmission 
Specifications. The second-generation waveforms specified by the 
Digital Video Broadcasting project offer two main enhancements. 
First, more efficient physical-layer methods that employ higher-order 
modulation with stronger FEC and permit adaptive coding and 
modulation response to changes in traffic and propagation conditions. 
Second, at the link layer, they offer greater flexibility in framing. 
Support is provided for a range of stream formats including the 
classical Transport Stream (TS) [RFC4259]. In addition, a new method 
called Generic Stream (GS) (or the Generic Mode) is supported. A GS 
can be packetized or continuous and is intended to provide native 
transport of other network-layer services. One such method is that 
provided by the Generic Stream Encapsulation (GSE) [GSE]. 


For example, the DVB-S2 [ETSI-S2] transmission link sequentially 
multiplexes a series of baseband frames (BBFrames). Each BBFrame 
comprises a fixed-size 10B header and a payload. The payload carries 
a DataField and uses padding to fill any unused space. A stream 
comprises a sequence of BBFrames associated with an Input Stream 
Identifier (ISI) that is carried in the header of each BBFrame. The 
simplest scheme uses a single stream (with just one ISI value), but 
multiple streams are permitted. The BBFrames forming a stream may be 
of variable size (selected from a set of allowed sizes), and must use 
the same stream format (i.e., TS or GSE). Each stream represents an 
independent link with independent address resolution [RFC4947]. 


GSE provides functions that are equivalent to those of the 
Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. It 
supports the transmission of IP packets and other network-layer 
protocols. The network-layer interface resembles that of ULE, where 
it adopts common mechanisms for a Length field, a 16-bit Type field, 
and support for Extension Headers. As in ULE, GSE permits multiple 
address formats, indicated by the LT field (functionally equivalent 


to the D field in ULE). The default addressing mode uses a 6-byte 
NPA and a suppressed NPA address (functionally equivalent to D=1 in 
ULE). 


GSE also provides more flexible fragmentation at the interface to the 
physical layer (using the S and E flags). This adapts the SNDUs to a 
variable-sized link-layer frame, and reflects the more complex 
requirements in terms of fragmentation and assembly that arise when 
using point-to-multipoint adaptive physical layers. The integrity of 
a reassembled SNDU is validated using a CRC-32 in the last fragment 
for the corresponding PDU. 
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